-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build(deps): bump actions/deploy-pages from 1 to 2 #701
build(deps): bump actions/deploy-pages from 1 to 2 #701
Conversation
suppose we need remove gh_pages branch to enable deploy pages? |
@evelikov highlighted the following steps to fully enable gh pages. I believe that removal gh_pages is optional in this respect (i.e. it becomes an obsolete branch once action is fully enabled). Here is this write up: #659 (comment) |
The problem with current actions setup for GH pages is that it's not easily re-triggerable. For example, here is action run when 2.18.0 was published: https://github.com/intel/libva/actions/runs/4543957752. It failed most likely since we did not actually perform required libva git project settings adjustment to enable posting of pages from our action. But problem is that even if I will fix project settings right now I can't retrigger this workflow - it simply miss re-trigger button for some reason. And I don't want to actually create new release just to retrigger a workflow. Considering that current pages are outdated with 2.13 release, I suggest to step back and do the following:
After that we can stop and consider that to do next. In a sense we can actually do nothing and just provide pages for the latest state on master which will be a candidate for new release. Or we can return back to original plan, though we will step again into the same problem that it won't be verifiable. What makes the most sense to me is actually generate pages for few states of the uAPI: 1) for master, 2) for latest release, 3) maybe for few latest releases. I would also do that from the master branch only to allow fixes of the posted materials when needed. @XinfengZhang, @evelikov : please, let me know your thoughts. If you are ok with the plan I can start doing it. |
@dvrogozh do you need to retrigger it manually, or is that a nice-to-have kind of feature? If it is a case of "need" then surely one will be creating a proper new release/tag. Thus the fix will shared with the wider community, right? |
No, not right. As of now I need to change github project settings and I don't have any way to retrigger workflow. So, if I will change project settings now, we will need to wait I don't know how long till we will post a new release, And if something won't work, we will wait again. This does not make sense to me. If there is a workflow I want to have a reasonable way to run/rerun it. As of now I don't have it. If there is a bug in workflow - I would fix it and again want a way for it to work w/o any release posting if no change was done to the actual library. |
I think this is the biggest concern here. It's even more alarming, that it comes from one of the maintainers. |
ask a dumb question , how about a tag, not official release, if a new tag will trigger the flow? |
You don not actually listen to the issue I am trying to raise regarding current supposed setup for pages deployment. |
As the workflow rules at the top say - it triggers on published aka releases. Whereas for the "I want to re-trigger manually" - you cannot AFAICT. As with any feature, if you want to try/test the changes simply push to your And yes, it's perfectly fine to push a release to address problems with the website. Releases are cheap, plus people generally appreciate more frequent ones. @dvrogozh I am (repeatedly) highlighting the elephant in the room. The current libva maintainership is very very poor - the questions you've raised flagging a part of it. Sorry if that upsets anyone, it is just the unfortunate facts. |
thanks , will improve this part, the response TPT , and sorry for any inconvenience . |
@dvrogozh I will release 2.19.0 soon, lets check whether the github setting works. |
f9ad877
to
f6a02b0
Compare
Bumps [actions/deploy-pages](https://github.com/actions/deploy-pages) from 1 to 2. - [Release notes](https://github.com/actions/deploy-pages/releases) - [Commits](actions/deploy-pages@v1...v2) --- updated-dependencies: - dependency-name: actions/deploy-pages dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
f6a02b0
to
6d39215
Compare
anyway, I merge this one firstly, following steps could be discussed in a new issue |
Bumps actions/deploy-pages from 1 to 2.
Release notes
Sourced from actions/deploy-pages's releases.
... (truncated)
Commits
73e62e6
Merge pull request #140 from actions/cut-v2b254707
Update the deployment API endpoints used by the api-client moduleYou can trigger a rebase of this PR by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)