It opens a menu that allows us to add the input we’ve set in the workflow yml. In the image we can see the “Run workflow” option (top-right). You just head over to the “Actions” tab, select the relevant action and the UI will take you from there: This way, a user can manually trigger a version bump from the Github web interface! Here we setup a workflow manual dispatch that accepts an input “version”. You can create a manual trigger in order to receive input from the user: on: In this case, you’d probably want to give the code some time to “cook” in main or develop before you release a stable release. You might not yet be confident enough in the process to deploy on push to main. You can even walk on the edge and deploy a stable version if all tests pass and you have enough confidence. You can run sanity checks, setup a canary deployment, deploy a next version of your app and more. What happens after we push to main ? That’s definitely up to you. This will usually happen after a pull request was merged (see Repository Integration Rules). In the above code we trigger on push to main. Now that we have our Pull Request covered, we’d like to handle the code after the integration: on: This is a good place to run your tests, linting and all the automated QA you can think of. Not only that, it will also trigger for any push to the branch that is initiating the pull request. The workflow will trigger on every pull request to the main branch. The above code is pretty much self explanatory. Here’s how it looks like: name: Pull Request #7: Use Your Own Docker Image in Github Actions.#6: Saving Computation Time by Stopping Obsolete Workflows.#4: Parallelism and Synchronous Operations.#3: Speeding the Workflows with Caching and Artifacts.#2: Reusable Workflows with Workflow Calls.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |