Closed f1ames closed 3 years ago
2. Attach code as a separate bash script, e.g.
run: sh ./path/to/script/script.sh
. We could do it by using submodules ornpm
package.
For a moment I was just thinking if we couldn't make .github/workflows/
directory a submodule itself but I guess it won't work this way unfortunately. :disappointed: I will look what is possible when I got back to this PR.
For a moment I was just thinking if we couldn't make
.github/workflows/
directory a submodule itself but I guess it won't work this way unfortunately. I will look what is possible when I got back to this PR.
Checked and it doesn't work... See also https://github.community/t/how-to-reuse-a-whole-workflow/17628/10. Still I wonder if we could have a single repo which will hold all common actions. And then a single action in each repo which will check for changes in actions-common (or listen on push event) and fetch new version and push to repo... This will help us easily develop and propagate new actions (like stalebot, deps updates, etc). It is similar to what @jacekbogdanski mentioned in:
2. Attach code as a separate bash script, e.g.
run: sh ./path/to/script/script.sh
. We could do it by using submodules ornpm
package.
But a little more automated and doesn't require moving entire logic to bash script.
Or the other way around as proposed in:
- Write it as a separate GH action - however it probably will require reimplementing imported actions in this workflow, which will lead to unnecessary code and take some time. We would need to check out if it's possible to reuse existing actions, otherwise, it doesn't really make sense due to required work.
If we can enclose what we have as a standalone action it would be pretty easy, but we need to check if action can use other actions (doesn't seem like it can so far, there are only composite run steps actions) - if not this will mean reimplementing all ready to use actions we are using now. And also comparing to above solution it would mean adding action file to each repo for each new action, while with the automatic propagation it will be automated.
Another option:
See GH docs - seems like it's purpose is what we need, so sharing workflows. However, it is per organization so we would to duplicate workflows between ckeditor
and cksource
. And also there are some limitations for private repos:
Workflow templates can be used to create new workflows in an organizations' public repositories; to use templates to create workflows in private repositories, the organization must be part of an enterprise or GitHub One plan.
And it still requires to manually enable actions in each repo. Not sure what happens if action template gets updated :thinking:
Regarding https://github.com/ckeditor/ckeditor4-angular/pull/144#issuecomment-715383138:
However, it is per organization so we would to duplicate workflows between
ckeditor
andcksource
. And also there are some limitations for private repos:
Checked with @vokiel and we are not able to use workflow templates with cksource
org. So we can have partial solution for ckeditor
only or go with more custom solution like mentioned in https://github.com/ckeditor/ckeditor4-angular/pull/144#issuecomment-715376131.
To sum up our F2F:
We discussed that we could have a small, single organization workflow installing a separate npm
package containing the rest of the workflows and reusing them in target repositories. I only start wondering how we could make sure that correct workflows are copied into .workflows
directory in a moment when workflow script is running. Maybe instead it would be better to just have npm script only, for each repository, which on postinstall
will copy workflows into .workflows
directory? Every our custom workflow could have npm i
action as a first step, so workflows are always up to date. WDYT?
Applied review suggestions to the update script. You can see how workflow works in https://github.com/f1ames/ckeditor4-angular/actions.
Also PRs (targeting both default branch and stable
) were are there - https://github.com/f1ames/ckeditor4-angular/pulls.
As mentioned in https://github.com/ckeditor/ckeditor4-angular/pull/144#issuecomment-717160001, I will setup the workflow as a follow-up (since we need to do this in other places) - see ckeditor/ckeditor4-workflows-common#1.
How would you see introducing these changes? Merging it into Angular and covering https://github.com/ckeditor/ckeditor4-workflows-common/pull/1/files separately once we test this action in production?
Well, we can merge it and if we are confident it's what we need move it to https://github.com/ckeditor/ckeditor4-workflows-common too so it can be reused in other repos.
Probably, we could also go with moving it to https://github.com/ckeditor/ckeditor4-workflows-common without merging but then we need to wait for https://github.com/ckeditor/ckeditor4-workflows-common and won't be able to have some initial runs in this repo. Since https://github.com/ckeditor/ckeditor4-workflows-common will auto-update this action if anything changes I don't see a reason not to merge it here too.
See https://github.com/f1ames/ckeditor4-angular/actions and https://github.com/f1ames/ckeditor4-angular/pulls.
As @Comandeer mentioned:
and so I have used
npm-check
package. This action also check if update devs branch already exists and skips updating if so (so it gives as time to check it).I guess we could squash commits in this branch before merging too.